controller/topup.go (1)

26-32: ⚡ Quick win

Graceful fallback recommended for GetUserGroup failures.

GetTopUpInfo is purely informational — it powers the topup page. If model.GetUserGroup returns an error (e.g., transient DB hiccup, stale session, or Redis<->DB inconsistency), the entire topup page now fails to load instead of falling back to a sane default, which is a UX regression compared to the pre-PR behavior where this lookup wasn't required at all.

Since common.GetTopupGroupRatio already returns 1 for unknown groups and getPayMoney defensively resets 0 ratios to 1, mirroring that defensiveness here keeps the page functional and only loses the (cosmetic) per-user discount preview.

♻️ Proposed graceful fallback

 func GetTopUpInfo(c *gin.Context) {
 	id := c.GetInt("id")
-	group, err := model.GetUserGroup(id, true)
-	if err != nil {
-		common.ApiError(c, err)
-		return
-	}
-	topupGroupRatio := common.GetTopupGroupRatio(group)
+	topupGroupRatio := 1.0
+	if group, err := model.GetUserGroup(id, true); err == nil {
+		if r := common.GetTopupGroupRatio(group); r > 0 {
+			topupGroupRatio = r
+		}
+	} else {
+		common.SysLog(fmt.Sprintf("GetTopUpInfo: failed to load user group for id=%d, falling back to ratio=1: %s", id, err.Error()))
+	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@controller/topup.go` around lines 26 - 32, GetUserGroup errors should not
abort GetTopUpInfo; instead fall back to a nil/unknown group so the page still
renders. Replace the current error branch in controller/topup.go (the call to
model.GetUserGroup and the ApiError return) with logic that on error logs the
failure (or ignores it) and sets group to a nil/unknown value so you can still
call common.GetTopupGroupRatio(group) to obtain the safe default
(common.GetTopupGroupRatio already returns 1 for unknown groups). Keep the
function names model.GetUserGroup and common.GetTopupGroupRatio to locate the
change.

web/classic/src/components/topup/index.jsx (1)

720-723: 💤 Low value

Inconsistent fallback for missing discounts (|| vs ??).

Line 722 uses parsedDiscounts[amount] || 1.0 while the new selectPresetAmount (lines 896-902) uses ?? with a Number.isFinite guard. With parseDiscountMap guaranteeing values are finite numbers, both paths agree on undefined → 1.0, but they disagree on 0 (treated as "missing → 1.0" by || and "valid 0% price" by ??). The same || is reused on line 951 for discountRate. While a discount of 0 is unusual, the divergence is a code smell that will eventually bite if such a config is introduced.

♻️ Proposed alignment

-    discount: parsedDiscounts[amount] || 1.0,
+    discount: Number.isFinite(parsedDiscounts[amount])
+      ? parsedDiscounts[amount]
+      : 1.0,

And similarly for the discountRate prop on line 951.

Also applies to: 891-907

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web/classic/src/components/topup/index.jsx` around lines 720 - 723, Replace
the loose-fallback (||) with the same finite-number guard used in
selectPresetAmount so zero discounts are preserved: where customPresets builds
discount using parsedDiscounts[amount] and where discountRate is derived, change
the logic to use Number.isFinite(parsedDiscounts[amount]) ?
parsedDiscounts[amount] : 1.0 (mirroring selectPresetAmount and parseDiscountMap
assumptions) so undefined maps to 1.0 but 0 remains a valid discount.

web/classic/src/components/topup/RechargeCard.jsx (1)

440-491: ⚡ Quick win

Hoist topupGroupRatio and topupRate to avoid recomputation per preset.

topupGroupRatio is already computed at component scope on line 135 as currentTopupGroupRatio, and the topupRate calculation appears identically at lines 440-444 (currency-rate display) and 487-491 (inside the preset .map). Recomputing them on every preset render is harmless but adds visual noise and risks the two definitions drifting apart in future edits — for example, if someone tightens the validation in one place but not the other, presets and the rate display could disagree.

♻️ Proposed refactor

   const currentTopupGroupRatio = Number(topupInfo?.topup_group_ratio) || 1;
+  const safeTopupRate =
+    Number.isFinite(Number(priceRatio)) && Number(priceRatio) > 0
+      ? Number(priceRatio)
+      : 1;
   const currentOriginalAmount =
-    Number(topUpCount || 0) * Number(priceRatio || 0) * currentTopupGroupRatio;
+    Number(topUpCount || 0) * safeTopupRate * currentTopupGroupRatio;

Then in the rate-display IIFE and inside the preset .map, replace the inline topupRate/topupGroupRatio definitions with the hoisted safeTopupRate/currentTopupGroupRatio values.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@web/classic/src/components/topup/RechargeCard.jsx` around lines 440 - 491,
Hoist the repeated computations for topupGroupRatio and topupRate so presets and
the rate display use a single source of truth: remove the duplicated local
definitions inside the IIFE rate-display and inside the presetAmounts.map
callback and reference the component-scoped currentTopupGroupRatio and a hoisted
safeTopupRate (compute once using getCurrencyConfig()/priceRatio validation
logic) instead; update places that currently declare topupGroupRatio and
topupRate to use currentTopupGroupRatio and safeTopupRate (or rename
consistently) so the rate display and per-preset calculations (in the
presetAmounts.map) share the same validated values.